src/components/TextInput/index.tsx (1)

9-12: ⚡ Quick win

value?: never makes the component uncontrolled-only and is an undocumented constraint.

Any caller that needs to reset or programmatically update the field (e.g., switching between snippets without unmounting) must rely on a key prop — this is a non-obvious coupling. Consider removing the never guard and delegating the choice of controlled vs. uncontrolled to the caller.

♻️ Proposed change

 interface TextInputProps extends RNTextInputProps {
   error?: boolean;
-  value?: never;
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/TextInput/index.tsx` around lines 9 - 12, The TextInputProps
interface currently forces uncontrolled-only usage by declaring value?: never;
remove that line so TextInputProps extends RNTextInputProps without overriding
value (or explicitly type value to match RNTextInputProps, e.g., value?: string
| undefined) to allow callers to choose controlled vs uncontrolled behavior;
update any related JSDoc/comments for the TextInput component to reflect that
controlled usage is supported and remove any code that relied on value being
forbidden.

src/hooks/persisted/useSettings.ts (1)

131-136: ⚡ Quick win

Export CodeSnippet — it's part of a public interface but inaccessible to consumers.

CodeSnippet is used in the exported ChapterReaderSettings interface, but is itself unexported. Any screen or hook that creates or manipulates codeSnippetsJS/codeSnippetsCSS entries must either redeclare the type inline or use any, defeating the purpose of the type.

♻️ Proposed fix

-type CodeSnippet = {
+export type CodeSnippet = {
   name: string;
   code: string;
   lang: 'js' | 'css';
   active: boolean;
 };

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/hooks/persisted/useSettings.ts` around lines 131 - 136, The CodeSnippet
type is used in the exported ChapterReaderSettings but is declared unexported;
export it so consumers can reference the exact type (export type CodeSnippet = {
name: string; code: string; lang: 'js' | 'css'; active: boolean; }). Update the
declaration of CodeSnippet to be exported and ensure any references
(ChapterReaderSettings, codeSnippetsJS, codeSnippetsCSS) use the exported type
rather than redeclaring or falling back to any.

src/screens/settings/SettingsCustomCodeScreen/Components/SettingsWebView.tsx (1)

82-114: 🏗️ Heavy lift

MMKV listener and webViewSource memo fight each other on every settings change.

webViewSource lists settings (line 313) — the entire useChapterReaderSettings() object — as a dependency. Because MMKV mutations cause settings to produce a new object, every setting change triggers a full WebView HTML rebuild and reload. This races with (and wins over) the MMKV listener's JS injection at lines 86-90, making the CHAPTER_READER_SETTINGS injection branch a no-op. The visible symptom is a WebView flash/blank-screen on every settings change in the preview.

The two mechanisms are redundant and conflicting. Pick one:

• Option A (simpler): Remove settings from webViewSource deps and let the MMKV listener drive runtime updates.
• Option B: Remove the MMKV listener's CHAPTER_READER_SETTINGS branch entirely and accept that the WebView does a full reload per change (acceptable for a settings preview).

Also applies to: 216-316

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Components/SettingsWebView.tsx`
around lines 82 - 114, The webview is being rebuilt on every settings change
because webViewSource depends on the entire useChapterReaderSettings() object,
which races with the MMKV listener updates; remove the redundant runtime
conflict by deleting the settings dependency from webViewSource (so
webViewSource no longer includes the useChapterReaderSettings() object) and rely
on the existing MMKV listener (MMKVStorage.addOnValueChangedListener) to inject
updates via webViewRef.current?.injectJavaScript for CHAPTER_READER_SETTINGS;
keep the CHAPTER_READER_SETTINGS injection branch in the listener and ensure
webViewSource still includes any static values it needs but not the full
settings object referenced by useChapterReaderSettings().

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/screens/settings/SettingsCustomCodeScreen/Components/CodeInput.tsx (1)

106-109: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

defaultValue can still desync displayed code from selected snippet.

At Line 108, uncontrolled input state can go stale when code changes without remount. If this was intentionally addressed in the caller, please ensure CodeInput is keyed per snippet instance.

#!/bin/bash
# Verify CodeInput is remounted per snippet in CodeRoute usage.
FILE=$(fd -i '^CodeRoute\.tsx$' src | head -n 1)
if [ -z "$FILE" ]; then
  echo "CodeRoute.tsx not found under src/"
  exit 1
fi

echo "Inspecting: $FILE"
rg -n -C4 '<CodeInput|key=' "$FILE"

Expected: each <CodeInput ... /> in CodeRoute.tsx has a stable per-snippet key (e.g., id/name/index).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Components/CodeInput.tsx`
around lines 106 - 109, The AnimatedTextInput in CodeInput uses defaultValue
which can desync when the prop code changes; convert it to a controlled input by
replacing defaultValue={code} with value={code} (keeping onChangeText={setCode})
inside the CodeInput component, or if you intentionally rely on remount
semantics instead, ensure every <CodeInput ... /> usage in CodeRoute supplies a
stable per-snippet key (e.g., snippet id/name/index) so the component remounts
when switching snippets.

android/app/src/main/assets/js/textRemover.js (1)

149-156: ⚡ Quick win

selectionchange fires continuously during drag — repeated layout thrashing on every event.

showSelectionUI() calls getComputedStyle(...), getBoundingClientRect(), and writes to ui.style.* on every selectionchange event, including during live drag-selection where events fire at high frequency. This causes forced synchronous layout (read-write-read cycles) on the render thread for each event.

Consider debouncing the repositioning logic, or at minimum separating the one-time DOM creation from the per-event layout pass:

+  let repositionTimer = null;
+
   document.addEventListener('selectionchange', function () {
     const selectedText = getSelectedText();
     if (selectedText) {
-      showSelectionUI();
+      clearTimeout(repositionTimer);
+      repositionTimer = setTimeout(showSelectionUI, 50);
     } else if (!isUIActive) {
       hideSelectionUI();
     }
   });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@android/app/src/main/assets/js/textRemover.js` around lines 149 - 156, The
selectionchange handler currently calls showSelectionUI() on every event (via
document.addEventListener('selectionchange')) which triggers repeated
getComputedStyle/getBoundingClientRect and style writes and causes layout
thrashing; change the logic so getSelectedText() still triggers visibility
checks but split creation vs layout: ensure showSelectionUI() only performs
one-time DOM creation when UI is not present (use isUIActive to gate creation)
and move expensive measurements/position updates into a debounced or
rAF-throttled function (e.g., a new repositionSelectionUI() invoked via
requestAnimationFrame or a short debounce) so high-frequency selectionchange
events only schedule a single layout pass rather than performing synchronous
read-write-read on every event; keep hideSelectionUI() behavior unchanged.

src/screens/settings/SettingsCustomCodeScreen/index.tsx (2)

80-106: 💤 Low value

Memoize renderScene to match renderTabBar and avoid scene re-mounts.

renderScene is recreated on every render, while renderTabBar is wrapped in useCallback. Passing a fresh function to TabView on each render can defeat its internal memoization and cause avoidable scene work. Wrapping it in useCallback (with editingSnippet and index in deps) keeps it consistent with renderTabBar.

Proposed refactor

-  const renderScene = ({
-    route,
-    jumpTo,
-  }: SceneRendererProps & {
-    route: {
-      key: string;
-      title: string;
-    };
-  }) => {
-    switch (route.key) {
-      case 'first':
-        return <SettingsRoute onEditSnippet={handleEditSnippet} />;
-      case 'second':
-        return (
-          <CodeRoute
-            jumpTo={jumpTo}
-            editingSnippet={editingSnippet}
-            onSnippetSaved={handleSnippetSaved}
-            isActive={index === 1}
-          />
-        );
-      case 'third':
-        return <SettingsWebView />;
-      default:
-        return null;
-    }
-  };
+  const renderScene = React.useCallback(
+    ({
+      route,
+      jumpTo,
+    }: SceneRendererProps & { route: { key: string; title: string } }) => {
+      switch (route.key) {
+        case 'first':
+          return <SettingsRoute onEditSnippet={handleEditSnippet} />;
+        case 'second':
+          return (
+            <CodeRoute
+              jumpTo={jumpTo}
+              editingSnippet={editingSnippet}
+              onSnippetSaved={handleSnippetSaved}
+              isActive={index === 1}
+            />
+          );
+        case 'third':
+          return <SettingsWebView />;
+        default:
+          return null;
+      }
+    },
+    [editingSnippet, index],
+  );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/index.tsx` around lines 80 -
106, renderScene is recreated on every render which breaks TabView's
memoization; wrap renderScene in useCallback and include editingSnippet and
index in its dependency array to mirror renderTabBar's behavior. Locate the
renderScene function and convert it to a const wrapped with useCallback,
preserving the switch cases that return SettingsRoute, CodeRoute (keep jumpTo,
editingSnippet, onSnippetSaved, isActive props and isActive computed from
index), and SettingsWebView, and ensure handleEditSnippet remains referenced;
this keeps TabView stable and prevents unnecessary scene remounts.

---

152-160: 💤 Low value

Remove unsupported collapsable prop from TabView.

The collapsable prop is not part of the react-native-tab-view 4.3.0 API and will be ignored. If optimization of the wrapping container is needed, apply collapsable to a View wrapper instead.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/index.tsx` around lines 152 -
160, The TabView usage passes an unsupported prop `collapsable`; remove
`collapsable={false}` from the TabView component in SettingsCustomCodeScreen so
the component only receives valid props (index/routes/navigationState,
renderScene, renderTabBar, onIndexChange, initialLayout, lazy). If you need the
optimization, wrap TabView with a React Native View and apply
`collapsable={false}` to that wrapper instead; locate the TabView JSX in the
SettingsCustomCodeScreen component (where renderScene and handleTabChange are
used) to make the change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/screens/reader/components/WebViewReader.tsx (2)

290-302: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Serialize injected metadata before embedding it in the script.

Reiterating the prior finding: novel.name, chapter.name, and novel.pluginId are interpolated raw into a quoted JS string. A ", backslash, or </script> in any of these external values can break parsing or escape the script context inside the WebView. Use JSON.stringify for each.

🛡️ Proposed fix

-                 function fn(){
-                     let novelName = "${novel.name}";
-                     let chapterName = "${chapter.name}";
-                     let sourceId = "${novel.pluginId}";
-                     let chapterId =${chapter.id};
-                     let novelId =${chapter.novelId};
+                 function fn(){
+                     let novelName = ${JSON.stringify(novel.name)};
+                     let chapterName = ${JSON.stringify(chapter.name)};
+                     let sourceId = ${JSON.stringify(novel.pluginId)};
+                     let chapterId = ${JSON.stringify(chapter.id)};
+                     let novelId = ${JSON.stringify(chapter.novelId)};
                      const qs = (s) => document.querySelector(s);
                      let html = qs("#LNReader-chapter").innerHTML;
                      ${customJS}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/WebViewReader.tsx` around lines 290 - 302, The
injected metadata (novel.name, chapter.name, novel.pluginId, etc.) are
interpolated raw into the inline script (inside function fn) and can break the
WebView/script if they contain quotes, backslashes, or "</script>"; replace the
direct string interpolations by serializing each value with JSON.stringify when
building novelName, chapterName, sourceId (and optionally chapterId/novelId) so
the generated JS receives safe, quoted JS literals; ensure the stringified
values are used where fn, novelName, chapterName, sourceId, chapterId, novelId
and customJS are referenced and keep the DOMContentLoaded listener intact.

---

159-163: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Accept 0 as a valid save position.

Same issue flagged previously: event.data && typeof event.data === 'number' skips 0, so a "top of chapter" progress save is silently dropped. Drop the truthiness check and rely on the typeof guard.

🐛 Proposed fix

             case 'save':
-              if (event.data && typeof event.data === 'number') {
+              if (typeof event.data === 'number') {
                 saveProgress(event.data);
               }
               break;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/WebViewReader.tsx` around lines 159 - 163, In
the 'case "save"' branch inside WebViewReader.tsx, the current guard `event.data
&& typeof event.data === 'number'` incorrectly rejects 0; change the check to
only verify the type (e.g., `typeof event.data === 'number'`) before calling
saveProgress(event.data) so zero is accepted as a valid position; locate the
switch branch handling 'save' and update the conditional there (keeping
saveProgress as the call target).

src/screens/settings/SettingsReaderScreen/SettingsReaderScreen.tsx (1)

14-55: 💤 Low value

Redundant Speech.stop cleanup with SettingsReaderWebView.

SettingsReaderWebView already stops speech in its own unmount effect. Since that component is unmounted when this screen unmounts, the screen's Speech.stop() cleanup (and the expo-speech import) is redundant and can be removed to keep the responsibility in one place.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsReaderScreen/SettingsReaderScreen.tsx` around
lines 14 - 55, Remove the redundant speech cleanup from the screen: delete the
"import * as Speech from 'expo-speech';" statement and remove the useEffect
teardown that calls Speech.stop() in SettingsReaderScreen; leave speech control
to SettingsReaderWebView (which already stops speech on unmount) and ensure no
other references to Speech remain in SettingsReaderScreen (remove or update any
unused imports/usages accordingly).

src/hooks/persisted/useSettings.ts (2)

374-379: ⚡ Quick win

Cast hides residual customJS/customCSS instead of stripping them.

chapterReaderSettings is built from storedSettings (a MigrationChapterReaderSettings), so the legacy customJS/customCSS fields can still be present on the returned object until MMKV rehydrates. The as ChapterReaderSettings cast just suppresses the type, but consumers spreading these settings (e.g., back into setSettings) will round-trip the legacy fields. Strip them explicitly when constructing the return value.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/hooks/persisted/useSettings.ts` around lines 374 - 379, The returned
object currently casts chapterReaderSettings to ChapterReaderSettings which
hides legacy fields (customJS/customCSS) coming from
storedSettings/MigrationChapterReaderSettings; instead explicitly remove those
keys when building the returned object so they cannot be propagated (e.g.,
create the return object by copying chapterReaderSettings but deleting customJS
and customCSS before spreading, then include setChapterReaderSettings,
saveCustomReaderTheme, deleteCustomReaderTheme) to ensure consumers (like
setSettings) won't round-trip legacy fields.

---

129-134: ⚡ Quick win

Consider exporting CodeSnippet.

This type is consumed by useCustomCode, SettingsCustomCodeScreen, ExportNovelAsEpubButton, SettingsReaderWebView, etc. Keeping it unexported forces those modules to redeclare or any-type the structure.

♻️ Proposed change

-type CodeSnippet = {
+export type CodeSnippet = {
   name: string;
   code: string;
   lang: 'js' | 'css';
   active: boolean;
 };

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/hooks/persisted/useSettings.ts` around lines 129 - 134, The CodeSnippet
type is currently unexported which forces other modules (useCustomCode,
SettingsCustomCodeScreen, ExportNovelAsEpubButton, SettingsReaderWebView) to
re-declare or use any; export the type by adding an export to the declaration
(export type CodeSnippet = {...}) so these consumers can import the shared type;
update any import sites to import { CodeSnippet } where needed.

src/screens/settings/SettingsReaderScreen/components/SettingsReaderWebView.tsx (1)

26-58: ⚡ Quick win

Hoist hardcoded novel/chapter constants out of the component body.

These objects are recreated on every render and used as the JSON.stringify payload for initialReaderConfig, which forces the WebView source.html string to differ on every render and may cause the WebView to reload more than necessary. Move them to module scope so the references are stable.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/screens/settings/SettingsReaderScreen/components/SettingsReaderWebView.tsx`
around lines 26 - 58, The hardcoded novel and chapter objects are defined inside
the SettingsReaderWebView component causing new references each render and
making the JSON.stringify payload for initialReaderConfig (used in the WebView
source.html) change every time; move the novel and chapter constants to module
scope (top-level) so they are stable across renders and update any references in
SettingsReaderWebView/initialReaderConfig to use those top-level novel and
chapter identifiers, ensuring the WebView source.html string remains stable
between renders.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

android/app/src/main/assets/js/textRemover.js (2)

48-49: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

window.getSelection() null check still missing.

window.getSelection() can return null in sandboxed/detached document contexts on Android WebView. Lines 48-49 (showSelectionUI), 127 (getSelectedText), 142 (removeSelectedText), and 155 (replaceSelectedText) all dereference the result without guarding.

🛡️ Proposed fix

   function showSelectionUI() {
     const ui = createSelectionUI();
 
     // Get selection bounds
     const selection = window.getSelection();
-    if (selection.rangeCount > 0) {
+    if (selection && selection.rangeCount > 0) {

   function getSelectedText() {
     const selection = window.getSelection();
-    if (selection.rangeCount > 0) {
+    if (selection && selection.rangeCount > 0) {
       return selection.toString().trim();
     }
     return '';
   }

     hideSelectionUI();
-    window.getSelection().removeAllRanges();
+    window.getSelection()?.removeAllRanges();
   }

Also applies to: 125-131, 141-142, 153-155

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@android/app/src/main/assets/js/textRemover.js` around lines 48 - 49, The code
calls window.getSelection() in showSelectionUI, getSelectedText,
removeSelectedText, and replaceSelectedText without guarding for a null return;
update each function to first assign const selection = window.getSelection();
then check if (!selection) { /* return safe default or no-op (e.g., return null
or false) */ } before accessing selection.rangeCount or selection.getRangeAt,
and ensure callers handle the safe default; this prevents dereferencing null in
sandboxed/detached WebView contexts.

---

87-99: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

reader global is still accessed without an existence guard.

The previous review flagged this — reader.generalSettings.val.verticalSeekbar and reader.hidden.val are dereferenced directly. If textRemover.js runs before reader is defined in the WebView (injection-order races), this throws a ReferenceError and the overlay silently fails to position. Same risk on Line 98.

🛡️ Proposed guard

-        const avoidScrollbar = reader.generalSettings.val.verticalSeekbar
-          ? 0
-          : 42;
-        const avoidUI = !reader.hidden.val ? 46 + avoidScrollbar : 0;
+        const hasReader = typeof reader !== 'undefined';
+        const avoidScrollbar = hasReader && reader.generalSettings?.val?.verticalSeekbar
+          ? 0
+          : 42;
+        const avoidUI = hasReader && !reader.hidden?.val ? 46 + avoidScrollbar : 0;
         topPosition = viewportHeight - bottomSafeArea - avoidUI - 4;
         ui.style.top = topPosition + 'px';
         ui.style.bottom = 'auto';
       } else {
         // Selection is in bottom half, position UI at top (accounting for status bar)
         topPosition = Math.max(topSafeArea, statusBarHeight + 20);
-        const avoidUI = !reader.hidden.val ? 34 : 0;
+        const avoidUI = (typeof reader !== 'undefined' && !reader.hidden?.val) ? 34 : 0;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@android/app/src/main/assets/js/textRemover.js` around lines 87 - 99, The code
dereferences the global reader (reader.generalSettings.val.verticalSeekbar and
reader.hidden.val) without guarding for its existence, causing a ReferenceError
if the WebView injects this script before reader is defined; update the
positioning logic in textRemover.js to check for reader (and nested properties)
before accessing them — e.g., use existence checks or optional chaining and
sensible defaults when computing avoidScrollbar and avoidUI, and apply the same
guard where reader.hidden.val is used before setting ui.style.top and
ui.style.bottom (references: reader, reader.generalSettings.val.verticalSeekbar,
reader.hidden.val, topPosition, ui.style.top).

src/screens/reader/components/Hooks/useTextModifications.ts (1)

82-91: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Replace flow still cannot update an existing rule.

Re-selecting text that already has a replacement opens the modal but handleReplaceSave silently no-ops because of the if (!(selectedTextForReplace in newReplaceText)) guard. Users have no way to edit or correct an existing replacement, and the function still returns true, so the caller treats it as success. Also consider seeding replacementText from the existing entry when opening the modal (Line 75) so the user can edit rather than start from empty.

🐛 Proposed fix

       } else if (action === 'replace') {
-        // Show modal for user to enter replacement text
         setSelectedTextForReplace(text);
-        setReplacementText('');
+        setReplacementText(readerSettings.replaceText[text] ?? '');
         setReplaceModalVisible(true);
       }
@@
   const handleReplaceSave = React.useCallback(() => {
     if (!selectedTextForReplace) return false;
 
     const newReplaceText = { ...readerSettings.replaceText };
-    if (!(selectedTextForReplace in newReplaceText)) {
-      newReplaceText[selectedTextForReplace] = replacementText;
-      setChapterReaderSettings({ replaceText: newReplaceText });
-    }
+    newReplaceText[selectedTextForReplace] = replacementText;
+    setChapterReaderSettings({ replaceText: newReplaceText });
     setReplaceModalVisible(false);
     return true;
   }, [

If handleTextAction is updated to also seed from existing rules, add readerSettings.replaceText to its dependency array.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` around lines 82
- 91, handleReplaceSave currently refuses to update an existing replacement
because of the guard if (!(selectedTextForReplace in newReplaceText)) and still
returns true; change it so that it always writes the replacement (assign
newReplaceText[selectedTextForReplace] = replacementText) and calls
setChapterReaderSettings({ replaceText: newReplaceText }) to update or create
the rule, then close the modal via setReplaceModalVisible(false) and return true
only on successful save. Also seed the modal's replacementText state when
opening the modal (where handleTextAction / modal-open logic sets
selectedTextForReplace) by looking up
readerSettings.replaceText[selectedTextForReplace] so the user can edit existing
entries, and if you update handleTextAction to read from
readerSettings.replaceText add readerSettings.replaceText to its dependency
array.

src/screens/reader/components/Hooks/useTextModifications.ts (1)

105-111: ⚡ Quick win

eventTextAction lacks defensive checks and consistent memoization.

The function has several issues:

• When event.data is an empty object, Object.keys(event.data)[0] is undefined. The subsequent cast as string masks this, silently passing 'undefined' to handleTextAction.
• Only the first key is consumed; additional fields are silently dropped.
• The function is not memoized despite handleTextAction being memoized, creating inconsistency.
• Explicit action narrowing to 'remove' | 'replace' would prevent unknown payloads from reaching the handler.

♻️ Proposed refactor

-  function eventTextAction(event: WebViewPostEvent) {
-    if (event.data) {
-      const action = Object.keys(event.data)[0];
-      const text = event.data[action];
-      handleTextAction(action as string, String(text));
-    }
-  }
+  const eventTextAction = React.useCallback(
+    (event: WebViewPostEvent) => {
+      const data = event?.data;
+      if (!data || typeof data !== 'object') return;
+      const [action] = Object.keys(data);
+      if (action !== 'remove' && action !== 'replace') return;
+      const text = data[action];
+      if (typeof text !== 'string' || !text) return;
+      handleTextAction(action, text);
+    },
+    [handleTextAction],
+  );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` around lines 105
- 111, eventTextAction currently reads only the first key, casts undefined to
string, and isn't memoized; update eventTextAction (used with WebViewPostEvent)
to be wrapped in useCallback and perform defensive checks: ensure event.data
exists and has entries, iterate over Object.entries(event.data) instead of
taking only the first key, validate each key is one of the allowed actions
('remove' | 'replace') before calling handleTextAction, and coerce the value
safely to string; skip any unknown keys so malformed payloads don't reach
handleTextAction.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx (3)

53-55: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Treat index === -1 as create mode, not edit mode.

The isEditing flag is true whenever editingSnippet is non-null, including when editingSnippet.index === -1 (create new snippet). This disables the language toggles (lines 190, 197) even in create mode. Gate edit mode on editingSnippet?.index !== -1 instead.

🔧 Proposed fix

-  const isEditing = editingSnippet !== null && editingSnippet !== undefined;
+  const isEditing =
+    editingSnippet !== null &&
+    editingSnippet !== undefined &&
+    editingSnippet.index !== -1;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx` around
lines 53 - 55, The isEditing flag currently treats any non-null editingSnippet
as edit mode (const isEditing = editingSnippet !== null && editingSnippet !==
undefined), which incorrectly marks index === -1 (create mode) as editing and
disables language toggles; change the gating to check editingSnippet.index !==
-1 (e.g., const isEditing = editingSnippet != null && editingSnippet.index !==
-1) and update dependent computed values (editIndex and editIsJS) to use this
revised isEditing so create-mode (index === -1) falls back to snippetIndex and
dLang respectively.

---

136-137: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Replace the snippet object instead of mutating it.

The shallow copy [...snippets] preserves the original object references. Mutating newSnippets[editIndex].name and .code directly modifies the original snippet object, which can break memoization in useCustomCode if it relies on referential equality.

♻️ Proposed fix

     // Editing existing snippet
     if (isEditing && editIndex !== undefined && editIndex !== -1) {
-      newSnippets[editIndex].name = title;
-      newSnippets[editIndex].code = code;
+      newSnippets[editIndex] = {
+        ...newSnippets[editIndex],
+        name: title,
+        code,
+      };
       setSettings({

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx` around
lines 136 - 137, The code mutates an existing snippet object by setting
newSnippets[editIndex].name and .code which preserves the original reference
from snippets and can break referential-equality checks in useCustomCode;
instead replace the whole snippet object at editIndex with a new object (e.g.,
create newSnippets by shallow-copying snippets and assign newSnippets[editIndex]
= { ...newSnippets[editIndex], name: title, code } or build the array via
snippets.map when index === editIndex) so the array and the modified item are
new references.

---

238-242: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Wire up or disable the "Open JS File" button.

This button has no onPress handler, so tapping it does nothing. Either implement the file-opening logic or set disabled={true} until the feature is ready.

🔧 Proposed fix (disable until implemented)

         <Button
           style={styles.button}
           title={getString('readerSettings.openJSFile')}
           mode="outlined"
+          disabled={true}
         />

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx` around
lines 238 - 242, The "Open JS File" Button in CodeRoute.tsx (Button with
style={styles.button} and title={getString('readerSettings.openJSFile')}) has no
onPress handler; either implement the handler (e.g., add a function like
handleOpenJSFile/openJSFile in the same component that performs the file-open
logic and pass it as onPress={handleOpenJSFile}) or disable the control while
unimplemented by adding disabled={true} to the Button; update any related
imports or state used by handleOpenJSFile and keep the Button reference
(styles.button/getString('readerSettings.openJSFile')) so the UI remains
consistent.

src/screens/reader/components/Hooks/useTextModifications.ts (2)

85-100: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Remove the guard that prevents updating existing replacements.

Lines 89-92 only save the replacement when the key doesn't already exist in newReplaceText. This makes replacement rules immutable after creation—users cannot correct or change a previous replacement.

🛠️ Proposed fix

   const handleReplaceSave = React.useCallback(() => {
     if (!selectedTextForReplace) return false;
 
     const newReplaceText = { ...readerSettings.replaceText };
-    if (!(selectedTextForReplace in newReplaceText)) {
-      newReplaceText[selectedTextForReplace] = replacementText;
-      setChapterReaderSettings({ replaceText: newReplaceText });
-    }
+    newReplaceText[selectedTextForReplace] = replacementText;
+    setChapterReaderSettings({ replaceText: newReplaceText });
     setReplaceModalVisible(false);
     return true;
   }, [

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` around lines 85
- 100, The guard in handleReplaceSave prevents updating existing replacement
entries; remove the conditional that checks if (selectedTextForReplace in
newReplaceText) so that newReplaceText[selectedTextForReplace] is always
assigned to replacementText and setChapterReaderSettings({ replaceText:
newReplaceText }) is called, then close the modal and return true; this ensures
selectedTextForReplace, newReplaceText, replacementText, and
setChapterReaderSettings are updated even when the key already exists.

---

75-80: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Pre-fill the replacement text when editing an existing rule.

When the user selects text that already has a replacement, line 78 always sets replacementText to an empty string. This hides the current value and prevents users from editing it.

🛠️ Proposed fix

       } else if (action === 'replace') {
-        // Show modal for user to enter replacement text
         setSelectedTextForReplace(text);
-        setReplacementText('');
+        setReplacementText(readerSettings.replaceText[text] ?? '');
         setReplaceModalVisible(true);
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` around lines 75
- 80, In useTextModifications, when handling action === 'replace' you clear the
existing replacement with setReplacementText(''), which prevents editing an
existing rule; instead look up the current replacement for the selected text
(from the rules state/collection used by this hook) and call
setReplacementText(existingReplacement || '') before
setReplaceModalVisible(true), leaving setSelectedTextForReplace(text) as-is so
the modal is pre-filled with the existing replacement for that selection.

src/screens/settings/SettingsReaderScreen/components/SettingsReaderWebView.tsx (2)

207-213: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Hide toggling is still one step behind.

The WebView gets the current hidden value and only then state flips, so the preview stays inverted until the next tap. Compute nextHidden once and use it for both operations.

🛠️ Proposed fix

           case 'hide':
-            if (hidden) {
-              webViewRef.current?.injectJavaScript('reader.hidden.val = true');
-            } else {
-              webViewRef.current?.injectJavaScript('reader.hidden.val = false');
-            }
-            setHidden(!hidden);
+            const nextHidden = !hidden;
+            webViewRef.current?.injectJavaScript(
+              `reader.hidden.val = ${nextHidden}`,
+            );
+            setHidden(nextHidden);
             break;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/screens/settings/SettingsReaderScreen/components/SettingsReaderWebView.tsx`
around lines 207 - 213, In the 'hide' branch (case 'hide') compute the
nextHidden value once (e.g., const nextHidden = !hidden) and use nextHidden for
both the injected JS call (via webViewRef.current?.injectJavaScript) and the
state update (setHidden(nextHidden)) so the WebView and React state are synced
immediately instead of being one tap behind.

---

75-82: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Generated snippet error handler is still invalid JS.

JSON.stringify(snippet.name) is still embedded inside a single-quoted literal, and \n becomes a real newline in the generated source. With any active JS snippet, this can make the injected fn() script fail to parse before the snippet even runs.

🛠️ Proposed fix

       try {
         ${snippet.code}
       } catch (error) {
-        alert('Error loading executing ${JSON.stringify(
-          snippet.name,
-        )}:\n' + error);
+        alert(
+          'Error executing ' +
+            ${JSON.stringify(snippet.name)} +
+            '\\n' +
+            error,
+        );
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/screens/settings/SettingsReaderScreen/components/SettingsReaderWebView.tsx`
around lines 75 - 82, The generated error alert embeds
JSON.stringify(snippet.name) inside single quotes and contains a real newline,
breaking the injected JS; in SettingsReaderWebView.tsx update the alert call
inside the template returned with snippet.code so that snippet.name is
concatenated (not inside the quoted literal) and the newline is escaped — e.g.
replace alert('Error loading executing ${JSON.stringify(snippet.name)}:\n' +
error); with a form that evaluates JSON.stringify(snippet.name) outside the
quoted string and uses '\\n' (for example: alert('Error loading executing ' +
${JSON.stringify(snippet.name)} + '\\n' + error);) so the produced fn() script
parses correctly.

src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx (1)

277-304: 💤 Low value

Remove unused style definitions.

The styles fakeTextInput, topField, codeField, and bottomField are defined but never used. The scrollContent style is an empty object. Consider removing these to reduce clutter.

♻️ Cleanup suggestion

   scrollContent: {},
-  text: {
-    flex: 1,
-  },
+  text: { flex: 1 },
   button: {
     marginHorizontal: 8,
     flexBasis: '40%',
     flex: 1,
   },
   snippetName: {
     marginTop: 8,
     marginBottom: 16,
   },
-  fakeTextInput: {
-    borderRadius: 4,
-    borderWidth: 1,
-    borderStyle: 'solid',
-    paddingHorizontal: 16,
-    paddingVertical: 10,
-    marginHorizontal: 1,
-    marginVertical: 2,
-  },
-  topField: {
-    borderBottomLeftRadius: 0,
-    borderBottomRightRadius: 0,
-    borderBottomWidth: 0,
-    flexGrow: 1,
-  },
-  codeField: {
-    verticalAlign: 'top',
-    flexGrow: 1,
-    borderRadius: 0,
-    borderTopWidth: 0,
-    borderBottomWidth: 0,
-  },
-  bottomField: {
-    flexGrow: 1,
-    borderTopLeftRadius: 0,
-    borderTopRightRadius: 0,
-    borderTopWidth: 0,
-  },
 });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/settings/SettingsCustomCodeScreen/Routes/CodeRoute.tsx` around
lines 277 - 304, Remove the unused style definitions from the Stylesheet: delete
the fakeTextInput, topField, codeField, and bottomField entries and remove the
empty scrollContent object from the styles block in CodeRoute.tsx so the styles
object only contains styles actually referenced by the component; search for
those symbol names (fakeTextInput, topField, codeField, bottomField,
scrollContent) to confirm they aren’t used elsewhere before deleting.

src/screens/reader/components/Hooks/useTextModifications.ts (2)

108-114: 💤 Low value

Consider stronger typing for WebView event data.

Lines 110-112 use Object.keys and type assertions to extract the action and text. If event.data has a known shape (e.g., { remove?: string; replace?: string }), adding a type guard or interface would catch errors earlier.

♻️ Example type-safe approach

function eventTextAction(event: WebViewPostEvent) {
  if (!event.data) return;
  
  if ('remove' in event.data && typeof event.data.remove === 'string') {
    handleTextAction('remove', event.data.remove);
  } else if ('replace' in event.data && typeof event.data.replace === 'string') {
    handleTextAction('replace', event.data.replace);
  }
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` around lines 108
- 114, The eventTextAction handler currently uses Object.keys and type
assertions on event.data which is brittle; update it to use a typed shape for
WebViewPostEvent (e.g., an interface with optional fields like remove?: string,
replace?: string) and add explicit type guards that check for the presence and
typeof the string before calling handleTextAction('remove' | 'replace', text).
Locate eventTextAction and replace the generic key extraction with guarded
branches that validate event.data.remove and event.data.replace (or a
discriminated union) so you avoid unsafe casts and guarantee correct types
passed to handleTextAction.

---

1-1: ⚡ Quick win

Prefer targeted logging over file-level eslint-disable.

Disabling no-console for the entire file hides future violations. Consider using the project's logger API (if available) for the console.warn calls at lines 21 and 28, or adding per-line exemptions instead of a blanket disable.

♻️ Proposed refactor

If a project logger is available:

-/* eslint-disable no-console */
 import { useChapterReaderSettings } from '@hooks/persisted/useSettings';
 import React, { useCallback, useMemo, useState } from 'react';
 import { WebViewPostEvent } from '../WebViewReader';
+import { logger } from '@utils/logger'; // adjust import path as needed

Then replace console.warn calls with logger.warn.

Alternatively, use per-line exemptions:

-/* eslint-disable no-console */
 import { useChapterReaderSettings } from '@hooks/persisted/useSettings';

And at each console call site:

       if (hasInvalidFlags) {
+        // eslint-disable-next-line no-console
         console.warn('Invalid regex flags in removeText:', text);
         return text;
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/screens/reader/components/Hooks/useTextModifications.ts` at line 1,
Remove the file-level "/* eslint-disable no-console */" in
useTextModifications.ts and either replace the two console.warn calls (the
warnings inside the useTextModifications hook at the sites currently using
console.warn) with the project's logger.warn API, or if a project logger isn't
available add per-line eslint disable comments directly above those two calls to
limit scope; update references to the unique symbol useTextModifications (and
the specific console.warn call sites) so the warning output uses logger.warn or
has a targeted eslint exemption.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes